Bugs in software may turn very expensive and can result in loss of life in the case of safety-critical software, product recalls in the case of embedded software and loss to business in other cases. Ensuring that a software application is bug-free is very difficult. Formal specification and verification of the entire software of such systems could be one way of demonstrating that an application is bug-free. However formal specification of the complete software is often unavailable, and in many cases not derivable. Moreover, when the program is complex, formally showing its correctness is often intractable.
Today, software testing serves as a practical and economic alternative to detect bugs in software. Testing methods have been extensively studied in the literature. Testing typically assesses the end-to-end quality of software by exercising the software on a representative set of test set to check if it meets the specified requirements. However, it is impossible to check program performance on all possible input data. An ideal test set should be large enough to effectively exercise most of the program executions, yet small enough so that the tester can comfortably run the program on it and compare the actual outputs with the expected outputs.
Lots of efforts have been made to develop effective software analysis, verification and testing tools, but still generating effective test data efficiently is a challenging task. Test generation is usually done with respect to some coverage criterion. The coverage could be either functional coverage or structural coverage of the code. There are various types of structural coverage criteria [9] such as statement, condition, decision, condition/decision, modified condition/decision coverage (MC/DC), multiple condition coverage (MCC). Ensuring that a test set satisfies a coverage criterion is an indirect measure of its effectiveness of detecting bugs.
In order to test software for relational bugs it is desirable to generate test data automatically with respect to any of the two coverage criteria Boundary Value Coverage (BVC) and Masking Boundary Value Coverage (MBVC).
However, the existing approach to address this problem of software testing is at the best by guided simulation. Thus, the existing method and systems are not capable of testing software by generating test data automatically and precisely with respect to two coverage criteria Boundary Value Coverage (BVC) and Masking Boundary Value Coverage (MBVC) due to insufficiency to scale up to analyze the software.
It is observed that the prior art remarkably fails to disclose an efficient method and system for software testing by automatically generating test data for these two coverage criteria. The existing solutions generally are not capable of testing software by generating test data automatically with respect to two coverage criteria Boundary Value Coverage (BVC) and Masking Boundary Value Coverage (MBVC) due to technical insufficiency to test the software code.